General Discussion
Effective business policies are critical for the success of any organization. This observation is almost as old as the term business itself. Having outdated policies can render a firm or organization out of competition in the current market. The strong correlation between success and effective business policies drives each and every business organization to keep their policies current and in sync with the operating business environments of the organization. In addition to keeping the existing policies current is the need to design new policies. With improving economic conditions, and increasing cost of manual labor, almost all enterprises try to automate the process of deploying, monitoring, and revising policies. The rapid growth of information technology has provided the choice of using software programs for such automations. Today, any policy can be encoded as a software program which in an automated setup, processes new events that were previously manually processed. Some of the advantages of using software encodings of the policies include elimination of human errors, higher efficiency of the process, and lesser cost. While this approach of using software programs encoding the policies is probably as good as any other solution as long as the policy is static (that is, it does not change once it has been established), its advantages are seriously challenged and undermined by today's dynamic business environment. In simple terms, when policies change, the software programs encoding such policies need to be modified accordingly. Such modifications will of course entail all of the delays and processes involved in the typical software development cycle. Thus, using software programs poses several inherent disadvantages, including the significant amount of time it takes for even a minor change in the policy to be implemented, and the significant resources required to effect such an implementation. The frequently changing policies and the challenges arising in managing the changes have fueled the growth of the business rules domain.
Among the several solutions that are offered by the business rules domain, we will concentrate only on those that deal with efficiently managing the changes in the policies. The central idea of these solutions is the concept of a business rule. A business rule essentially captures the logical formulation of some aspect of an organization's business. Stated below is OMG's (Object Management Group, www.omg.org) definition of a business rule.
“The essence of a business rule is to express a crisp logical definition of some facet of the organization's way of doing business. It is a statement that defines or constrains some aspect of the business. This must be either a term or a fact, a constraint, or a derivation. It is atomic in that it cannot be broken down or decomposed further into more detailed business rules, without sacrificing important information.”
The current solutions offered in the business rules domain include extracting the critical rules from the policies and treating them separately and differently from other parts of the business policy. An underlying hypothesis in connection with this is that when a policy changes, it is the rules part of the policy that changes, rather than the overall structure. Thus, implementing such changes involves only changing the rules, and the other parts need not be modified or adjusted.
Consider the following simple example where the solutions available currently in the business rules domain can be applied. A property mortgage company, say Fictitious Mortgaging Corp. grants loans against mortgaged property using among several other things, the details about applicant's income, her/his credit rating, the type of the property, etc. Below is a simplistic policy followed by the organization to decide whether a loan application for a specific type of loan should be approved or not.
1. If applicant's annual income<minimum annual income limit
Then Reject loan application.
2. If applicant's credit score<minimum credit score limit
Then Reject loan application.
3. If number of bankruptcies in applicant's credit report>0
Then Reject loan application.
4. If none of the above conditions hold
Then Approve loan application.
The policies followed by an actual mortgaging company would be much more complex than the one above. Also, an actual policy would probably contain specific values for the business terms, specifying for example ranges for minimum annual income limit and minimum credit score limit. However, this simplistic example helps us to consider and specify the underlying challenges of modifying and analyzing business rules without getting into unnecessary details.
To begin with, notice that although an actual policy may be worded differently, in most of the cases, it can be re-written as a set of If-Then clauses on business terms somewhat similar to the ones above. This situation is an apt case for the use of a business rules engine, which essentially simplifies the task of maintaining and deploying such business policies, and applying them for processing events such as a new loan application. The use of business rules engines is quite common today, to the extent that a policy is frequently referred to as a ruleset, which is generally considered to simply be a set of rules encoding the policy. As mentioned earlier, the traditional solutions of using software programs for automating policies are not suitable for today's dynamic environment. On the other hand, encoding them as rules and maintaining them separately makes such things easier. That is to say, using a business rules engine to manage policies makes it easier to manage the changes in the policies as and when they happen. Further details about the advantages of business rules engine are beyond the scope of our discussion.
The policy designers, who decide on the precise contents of the policies, and specific details, such as the values for minimum annual income limit and minimum credit score limit often use intuition, personal insights, and statistical reports, which may be generated using some data analysis tools, on the data about loan applications from the past. During the policy's design phase, the policy makers are often faced with questions about what would the optimal value be for a particular parameter (business term) in the policy. For example, how does one decide upon the right values for the business terms minimum annual income limit and minimum credit score limit? As of today, the policy makers need to rely on a static analysis of data (e.g. online analytical processing or fast analysis of shared multidimensional information, predictive data mining, etc.) which possibly has no relation to the intended purpose of the data analysis reports.
For example, a policymaker would probably be very interested in studying how an organization's business targets would be affected, if the policymaker chooses a minimum credit score limit of 620 instead of 580. Such decisions based on static data analysis typically demand that the entire data analysis be redone. Many automated analysis tools and techniques are available today for analyzing static data. Data mining tools are used heavily for studying the trends in the historical data, and using that information to predict the future trends. However, analyzing business rules needs the data to be analyzed in conjunction with the rules themselves, and the data analysis which does not include the information about the rules may not present the right picture.
b. An Abstract Procedure for Policy Design and Analysis
FIG. 1 depicts a traditional method of policy design and analysis. Below is a detailed discussion about the steps involved in such processes.
1. Design a preliminary version of the policy. This is the starting point of the process. The preliminary version may be the current version of the policy, or a completely new one designed from scratch.
2. Gather data analysis reports. This part of the process deals with performing static data analysis on the historical data maintained by the organization. Some relevant details regarding the policy may be included in the data analysis specifications.
3. Generation of data analysis reports. The data analysis module, which interacts with the historical database, generates the analytical reports as requested by the user, and presents them for investigation to the user.
4. Investigate the data analysis reports. The user needs to carefully study the reports in accordance with the policy itself. She/he may choose to consult other policy designers in the organization.
5. Reports Look Satisfactory? If the reports do not look satisfactory, the user creates a new version of the policy appropriately, and then returns to step 2. Otherwise, the process stops.
Note that this model is only an abstraction of the entire process, and the actual process followed by an individual may differ in certain aspects. For instance, the user may request a data analysis expert to generate several analytical reports, with some variations in each of them. Also, the communication between the policy designer and the data analytics expert should ideally be noise-free to ensure that the analytical reports actually conform to the details specified by the former. Another drawback with having the analytical part of the process delegated to an area expert is the slower turn-around time of the process.
Moreover, the most significant drawback of such schemes is that the static data analysis report can be tuned to the policy only up to a limited extent, and the validity of the reports in view of the policy being analyzed may be questionable. Typically, the policy designer uses her/his intuition, insight and personal experience to account for such and other limitations of these techniques.
Finally, accessing a historical database may not always be convenient, and the analysis process may also be hampered by such issues. The model's dependence on historical data thus proves to be a handicap for the policy designers intending to work at remote or mobile locations (assuming, of course that the historical database is accessible only on the organization's intranet—which is typically the case). The historical database dependency also limits the scope of analysis to the time period and populace for which sufficient amount of data is available.
c. Decision Analysis Tools with Simulations
Some decision analysis tools do support what-if analysis using Monte Carlo simulations. However, such systems do not adequately support rule-based systems. Another aspect of such tools is that they are more tuned to performing the analysis on a set of mathematical equations and/or decision trees modeling the underlying policy. The analytics model thus differs significantly from the actual model in which the policy is deployed. In other words, the simulation based analytics tools do not serve to analyze business rules, which is arguably the most popular model for deploying business policies today.
d. Static Data Analysis Techniques
As mentioned earlier, powerful data analytics tools are the favorite resources used by the policy designers/analysts. With the advent of On-Line Analytical Processing (OLAP) technology, many sophisticated data analysis tools are accessible today. Though many of these have been automated to a large extent, they suffer because of the steep learning curve, and remain restricted to experts in the data analytics domain. A business policy designer, more often than not, delegates the tasks of generating the analysis reports to such experts.
Another more serious issue concerns the validity of these static data analysis reports. While these reports may serve well for studying the trends in data, with a possible indication of the future trends, or the direction in which the market might shift, they may not be very well suited for studying business policies. While it may be possible to have the analysis tuned (to a certain extent) to a business policy being studied, it requires a significant amount of time and other resources to facilitate the necessary communication between the policy designer and the data analytics expert. Consequently, the data analysis reports, which form a critical part of the entire process, become more sensitive to the accuracy with which the policy designer is able to explain the details to the analytics expert. These and other technicalities essentially degrade the efficiency and reliability of such traditional procedures of policy design and analysis.
e. Personal Variations
Though the methodology followed by most of the policy designers fits the abstract framework de-scribed above, the exact process followed by each designer may vary with the individual. Most of such variations occur in the steps 2 and 3 of procedure outlined above. For instance, an individual may prefer a different type of analysis report than someone else. Another variation may be in the weight assigned to the analysis reports in comparison with personal insight and experience. A policy designer may decide to view the past statistical reports on the day-to-day events logged by the deployment mechanism of an existing policy, or choose to study different statistical metrics altogether. Given these variations, the traditional methods remain largely manual as opposed to automated, invariably involving multiple individuals which inherently slows down the entire process.